Database Management System

ABSTRACT

A multi-user, elastic, on-demand, distributed relational database management system. The database is fragmented into distributed objects called atoms. Any change to a copy of an atom at one location is replicated to all other locations containing a copy of that atom. Transactional managers operate to satisfy the properties of atomicity, consistency, isolation and durability.

CROSS REFERENCES TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 13/525,953 filed Jun. 18, 2012 for a Database Management Systemwhich is a division of U.S. patent application Ser. No. 13/051,750 filedMar. 18, 2011 for a Database Management System, now U.S. Pat. No.8,224,860 granted Jul. 17, 2012 which claims priority from U.S.Provisional Patent Application Ser. No. 61/315,351 filed Mar. 18, 2010for a Database Management System.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention generally relates to database management systems. Morespecifically this invention relates a method and apparatus forimplementing a multi-user, elastic, on-demand, distributed relationaldatabase management system characterized atomicity, performance andscalability.

2. Description of Related Art

Over the past years the use of databases for storing and retrievingmessages has emerged as an important tool in a wide variety ofcommercial applications. Initially, many database systems operated on asingle server installation with multiple users. However, various factorshave developed over the past years that have required the basic natureof database architecture to change. As a first factor, database storagerequirements have become extremely large. Second, the number of userstrying to access such databases has also become large. Third, the use ofdatabases to retrieve relatively stable data with minimal updates hasbeen replaced by transactional processing.

A transaction is a unit of work must be completed in its entirety. Asingle transaction may include multiple data manipulations. As anexample a single transaction may include a reading operation followed bya write operation. In recent years significant effort has been directedto enabling relational databases to support ever increasing rates oftransaction processing.

Databases are now judged by a standard that defines ACID properties,namely: atomicity, consistency, isolation and durability. Atomicityguarantees that all transaction tasks will be completed in theirentireties. Consistency assures is that only valid data is written tothe database. Isolation assures that other operations cannot access or“see” data in an intermediate state during a transaction. Durabilityassures that once a transaction has been processed successfully, itcannot be undone.

Consistency is particularly important in multi-user systems where it ispossible for two or more users to seek concurrent access to sharedvolatile data. Early multi-user systems used locking operations toassure consistency. Locks could be exclusive, or write, locks, ornon-exclusive, or read, locks and could be applied to individual recordsor to pages. However, as databases have grown in size and as transactionrates have increased, the overhead for managing locks has becomesignificant and, in some cases, prohibitive.

Multi-version concurrency control (MVCC) is an alternative process forassuring concurrency. MVCC can be more effective than locks with complexdatabases. MVCC uses timestamps or increasing transactionidentifications (IDs) to serialize different versions of a record. Eachversion permits a transaction to read the most recent version of anobject which precedes the timestamp or ID. With this control method, anychange to a record, for example, will not be seen by other users untilthe change is committed. MVCC also eliminates locks with other attendantoverhead and establishes a system in which read operations can not blockwrite operations.

In addition to meeting the ACID tests, there now is a requirement forcontinuous availability to users. Some database systems dedicate onecomputer system to transaction processing and another to decisionsupport and other reporting processes. They are interconnected so thatother functions can be supported simultaneously. As databases grow insize and complexity, existing data processing systems are replaced bymore powerful data processing system. Another approach for accommodatinggrowth involves replicated systems where one machine is designated as a“head” machine that keeps all the replicated machines in synchronism. Ifa head machine were to fail, a process would assign that function toanother replicated machine. Different replicated machines are availableto certain users. This approach is not scalable because all the machineshave to have the same capability.

As another approach, multiple autonomous database systems can beintegrated into a single “federated” database with a computer networkinterconnecting the various individual databases. Federated databasesrequire “middleware” to maintain the constituent databases insynchronism. This “middleware” can become very complex. As the databasesize increases, the resources required for operating the middleware mayimpose such a sufficiently great overhead that overall systemperformance degrades.

“Partitioning” is another approach for implementing databases in which alogical database or its constituent elements are divided into distinctindependent parts. In a distributed database management system, eachpartition may be spread over multiple nodes. Users at given node canperform local transactions on the partition. Partitioning also can beimplemented by forming smaller databases or by splitting selectedelements of just one table.

There are two general approaches to partitioning. In horizontalpartitioning, also called “sharding”, different rows are placed indifferent tables and different servers. Generally they have a certaincommonality such as a range of zip codes or last names which are dividedinto different tables by ranges. For example a first database mightcontain all the records for last names in the range A through M; asecond database, in the range N through Z. Sharding, which is a form ofhorizontal partitioning, involves locating rows of a database onseparate servers. Sharding does reduce the number of rows in each tableand increases search performance. However, sharding uses a hash code atan application level that makes it much more difficult to implement. Italso incorporates a two-phase commit. The complexities of sharding makeit suitable for particular applications as the basis for defining theshards is quite well defined.

Vertical partitioning involves the creation of tables with fewer columnsand splitting columns across tables. Like a federated database, verticalpartitioning requires middleware to determine how to route any requestfor a particular field to an appropriate partition. In addition thesesystems operate using a two-phase commit sequence which is complicatedto implement.

In still another approach, known as a “shared-nothing” architecture,each node is independent and self-sufficient. Shared-nothingarchitecture is popular for web development because it can be scaledupward simply by adding nodes in the form of inexpensive computers. Thisapproach is popular in data warehousing applications where updates tendto be less frequent than would occur with transaction processing.However, the processing of joins is very complex over large data setsfrom different partitions or machines.

Some database systems are referred to as “distributed” systems. Oneimplementation of a distributed system incorporates “clusters” and twocommunications paths. A high-speed Internet path carries data among theclusters. High-speed dedicated communications paths are required forvarious control functions, such as lock management. While this approachsolves the redundancy and availability issues for databases, lockmanagement, as previously discussed, can limit system performance.

In a “shared everything” system, super high-speed communications keepthe system in synchronism. However lock management can requiresignificant bandwidth resources. To avoid this, such systems incorporatepoint-to-point communications channels and a very sophisticated diskcontroller.

Collectively, those prior art systems satisfy some but not all of theknown requirements for a database system. What is needed is a databasearchitecture that is scalable, that meets the ACID properties ofatomicity, consistency, isolation and durability. What is also needed isa database system that operates over the Internet without the need fordedicated high-speed communications paths, that provides transactionprocessing and that is operable over a wide geographic area.

SUMMARY

Therefore, it is an object of this invention to provide an elastic,scalable, on-demand, distributed data processing system.

Another object of this invention is to provide an elastic, scalable,on-demand, distributed data processing system that is fault tolerant.

Still another object of this invention is to provide an elastic,scalable, on-demand, distributed data processing system that has a highdegree of availability.

Yet another object of this invention is to provide an elastic, scalable,on-demand, distributed data processing system that is platformindependent.

Still yet other object of this invention is to provide an elastic,scalable, on-demand, distributed data processing system that is atomic,consistent, isolated and durable.

Yet still another object of this invention to provide an elastic,scalable, on-demand, distributed data processing system that operatesover the Internet without a need for dedicated high-speed communicationspaths.

Still yet another object of this invention is to provide an elastic,scalable, on-demand, distributed data processing system that providestransaction processing and that is adapted for implementation over awide geographic area.

In accordance with one aspect of this invention a database managementsystem that enables users to interact with a database comprised of dataand metadata comprises a plurality of nodes and persistent storage withcommunications paths therebetween. Each node includes an interfacebetween high level-input and output commands at a user level and inputand output commands at the system level that control a sequence ofoperations for interacting with the database, wherein, in response tocertain system level commands, atom objects generate atoms, each atomcontaining a specified fragment of data or metadata whereby a set of allinstances of atoms collectively define all the metadata and data in thedatabase. Each node additionally includes a communications control forestablishing a communications path with each other node in the system, amethod responsive to a system command from the interface for requestingfrom a selected node copy of an atom that is relevant to the query butis not present in that node, a method responsive to a request for anatom from another node for replicating the requested atom for transferto the requesting node whereby only atoms required to complete a queryneed be located in any transaction node at any given time, and a methodresponsive to a change in an atom at that node for replicating that atomfor transfer to every other node in the system in which that atom isresident. The persistent storage contains a collection of atoms thatcollectively contain all the data and metadata in the database.

In accordance with another aspect of this invention database managementsystem that enables users to interact with a database comprised of dataand metadata, said system includes at least one transactional node thatprovide users with access to the database and at least one archival nodethat maintains an archive of the entire database. Each transactionalnode includes a database request engine that provides an interfacebetween high level-input and output query commands at a user level andinput and output commands at the system level that control a sequence ofoperations for interacting with the database. In response to certainsystem level commands, atom objects generate atoms. Each atom contains aspecified fragment of data or metadata whereby a set of all instances ofatoms collectively define all the metadata and data in the database. Adatabase system network interconnects all the nodes. A communicationscontrol in each of the nodes for establishes a communications path witheach other node in the system, A method in each transactional noderesponds to a system command from the database request engine forrequesting a copy of an atom that is relevant to the query command butis not present in that node. Another method in each node responds to arequest for an atom from another node for replicating the requested atomfor transfer to the requesting node whereby only atoms required tocomplete a query command need be located in any transactional node atany given time. Another method in each transactional node responds to achange in an atom at that node for replicating that change to everyother node in the system that contains a copy of that atom

In accordance with yet another aspect of this invention a databasemanagement system for a logical database comprised of data recordsorganized into tables that is to be accessed from multiple transactionalnodes that process transactions related to the logical data base whereinthe database is parsed into fragments wherein each fragment stores aportion of the metadata and/or data pertaining to the logical data basefor transfer within the database management system as serializedmessages and for storage as a de-serialized message. The system includesat least one archival node that stores all the fragments in ade-serialized form in permanent storage thereby to constitute a singlestore for the entire data base. Each transactional node responds toqueries from users by establishing a sequence of low-level commands foridentifying fragments that are relevant to the query and responds to thelow-level commands by obtaining only those copies of existing fragmentsthat are relevant to the query being processed thereat whereby a givenfragment might exist at some other node or only at an archival node.Each transactional node replicates any changed fragment to the at leastone archival node and each transactional node in which a copy of thatfragment resides whereby changes are made to fragments in other nodes ona peer-to-peer basis and whereby any transactional node only containsthose fragments that pertain to the queries being made users accessingthe data base through that transactional node.

BRIEF DESCRIPTION OF THE DRAWINGS

The appended claims particularly point out and distinctly claim thesubject matter of this invention. The various objects, advantages andnovel features of this invention will be more fully apparent from areading of the following detailed description in conjunction with theaccompanying drawings in which like reference numerals refer to likeparts, and in which:

FIG. 1 is a diagram in schematic form of one embodiment of an elastic,scalable, on-demand, distributed data processing system thatincorporates this invention with interconnected transactional andarchival nodes;

FIG. 2 depicts the organization of a transactional node;

FIG. 3 depicts the organization of an archival node;

FIGS. 4A and 4B depict the logical organization of “atom” objectsgenerated by atom classes shown in FIGS. 2 and 3 that are useful inimplementing this invention and they might appear at any given time in atransactional node;

FIG. 5 depicts the information in a Master Catalog atom;

FIG. 6 depicts the information in a Transaction Manager atom;

FIG. 7 depicts the information in a Database atom;

FIG. 8 depicts the information in a Schema atom;

FIG. 9 depicts the information in a Table atom;

FIG. 10 depicts the information in a Table Catalog atom;

FIG. 11 depicts the information in an Index atom;

FIG. 12 depicts the information in a Record States atom;

FIG. 13 depicts the information in a Data atom;

FIG. 14 depicts the information in a Blob States atom;

FIG. 15 depicts the information in a Blob atom;

FIG. 16 depicts the syntax of a exemplary asynchronous message that istransferred among the transactional and archival nodes of the databasesystem of FIG. 1;

FIG. 17 depicts various messages types by which information istransferred among the transactional and archival nodes of the databasesystem of FIG. 1;

FIG. 18 is a flow diagram useful in understanding the method by which anode joins the database system in FIG. 1;

FIG. 19 depicts the information in a node object;

FIG. 20 is a flow diagram useful in understanding the method by which anode creates an atom in accordance with this invention;

FIG. 21 is a flow diagram useful in understanding the method by whichunique atom identifications are assigned during the method of FIG. 20;

FIG. 22 is a flow diagram useful in understanding the method by whichone node obtains a copy of an atom from another node; and

FIG. 23 is a flow diagram useful in understanding a method by which thisinvention commits a transaction.

DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

FIG. 1 depicts one embodiment of an elastic, scalable, on-demand,distributed database system 30 with a plurality of data processing nodesthat incorporates this invention. Nodes N1 through N6 are “transactionalnodes” that provide user applications access to the database; nodes A1and A2, “archival nodes” that function to maintain a disk archive of theentire database at each archival node. While an archival node normallystores the entire database, a single transactional node contains onlythat portion of the database it determines to be necessary to supporttransactions being performed at that node at that time.

Each node in FIG. 1 can communicate directly with each other node in thesystem 30 through a database system network 31. For example, node N1 canestablish a communications path with each of nodes N2 through N6, A1 andA2. Communications between any two nodes is by way of serializedmessages. In a preferred embodiment, the messaging is performed in anasynchronous manner to maximize the bandwidth used by the system therebyto perform various operations in a timely and prompt manner. Typicallythe database system network 31 will operate with a combination ofhigh-bandwidth, low-latency paths (e.g., an Ethernet network) andhigh-bandwidth, high-latency paths (e.g., a WAN network). Each node hasthe capability to restrict use of a low-latency path to time-criticalcommunications (e.g., fetching an atom). The high-latency path can beused for non-critical communications (e.g. a request to updateinformation for a table). Also and preferably, the data processingnetwork of this invention incorporates a messaging protocol, such as theTransmission Control Protocol (TCP), and assures that each nodeprocesses messages in the same sequence in which they were sent to it byother nodes.

FIG. 2 depicts a representative transactional node 32 that links to thedatabase system network 31 and various end users 33. The transactionalnode 32 includes a central processing system (CP) 34 that communicateswith the database system network 31 through a network interface 35 andwith the various users through and user network interface 37. Thecentral processing system 34 also interacts with RAM memory 38 thatcontains a copy of the database management program that implements apreferred embodiment of this invention. This program functions toprovide a remote interface 40, a database request engine 41 and a set 42of classes or objects.

The database request engine 41 only exists on transactional nodes and isthe interface between the high-level input and output commands at theuser level and system level input and output commands at the systemlevel. In general terms, its database request engine parses, compilesand optimizes user queries such as SQL queries into commands that areinterpreted by the various classes or objects in the set 42.

For purposes of the explanation of this invention, the setclasses/objects set 42 is divided into a subset 43 of “atom classes,” asubset 44 of “message classes” and a subset 45 of “helper classes.”Additional details of these classes are described later.

As will become apparent and in accordance with this invention, at anygiven time a transactional node only contains those portions of thetotal database that are then relevant to active user applications.Moreover, the various features of this invention enable all portions ofdatabase in use to be resident in random access memory 38. There is noneed for providing supplementary storage, such as disk storage, at atransactional node during the operation of this system.

Referring to FIG. 3, each archival node 50, such as archival node A1 orA2 in FIG. 1, also connects to the database system network 31. However,in place of end users 33 associated with a transactional node 32 in FIG.2, an archival node connects only to persistent storage 51, typically adisk-based storage system or a key value store. The archival node 50includes a central processing system 54 that communicates with thepersistent storage 51 through an I/O channel 52 and with the databasesystem network 31 through a network interface 55. The central processingsystem 54 also interacts with RAM memory 57 that contains a set 62 ofclasses or objects. Similarly to the transactional node 32 in FIG. 2,the classes/objects set 62 in FIG. 3 includes a set 63 of “atomclasses,” a set 64 of “message classes” and a set 65 of “helperclasses.”

A preferred embodiment of this invention uses object-orientedprogramming (OOP) wherein, as known in the art, classes and subclassessuch as shown in FIGS. 2 and 3 define methods, data structures andprocesses by which an “instance”, or object, of that class or subclassmay be generated. An “instance” may be generated using “inheritance”and/or “polymorphism.” It will become apparent to those skilled in theart that implementations are possible that do not use object-orientedprogramming or variations on the specifically disclosed embodiment.

This invention will now be described in several phases. An “Atoms”section defines the hierarchy and function of objects produced by theatom classes 43 and 63 in FIGS. 2 and 3 respectively. A “Messages”section describes a set of messages which provide communications amongthe transactional and archival nodes as might be produced by messageclasses 44 and 64 in FIGS. 2 and 3 respectively. A “Methods” sectiondescribes basic operations with respect to database management. An“Example” section describes the interaction of the atom, message andmethods by which the objectives of this invention are achieved inresponse to a specific database query to the database request engine 41.

Atoms

As previously stated, each of the atom classes 43 in FIGS. 2 and 63 inFIG. 3 produce “atoms”. More specifically, the atom classes define oneor more “atom types” or “atom objects.” Each “atom type” or “atomobject” produces an “instance” of itself, that is, an “atom.” As willbecome apparent with a more detailed understanding of the purpose ofeach specific atom object, each “atom” contains a specific fragment ofdatabase information. Some atoms contain a portion of the databasemetadata; others contain data records; still others serve as catalogsthat create and track other atom types. Some “atom types” may onlyinstantiate one atom which replicates to all nodes. Other “atom types”may instantiate multiple atoms which are replicated to other nodes on anas-needed basis.

Atoms have certain characteristics. In a transactional node, an atomexists only in non-persistent memory and in the form of a de-serializedmessage that has populated a particular atom type to provide anefficient memory resident format for the atom. Each atom has means forencoding its content into a serialized message and means for decoding aserialized message to retrieve the contents of the atom. Such serializedmessages are used in connection with a number of operations as will bedescribed later.

Each serialized message transmitted from a node for replicating an atomincludes the content of that atom with an appended node identificationand the most recent transaction commit sequence number for that node.When an archival node receives that serialized message, it de-serializesthe message, removes the node list and commit sequence number beforeplacing the remaining content of the message (i.e., an atom) inpersistent storage.

A number of rules apply to atoms in accordance with this invention. Thereasons and implications of those rules will become more apparent.First, each atom must have a unique identification to provide a reliableidentification of that atom anywhere in the database processing network30 in FIG. 1. Second, any atom must exist in two nodes simultaneously tomaintain redundancy, except that a single atom can exist after it iscreated and before an archive node has requested a copy. Third, atransactional node will load an atom only on demand. Fourth, each time achange is made to an atom in one node, that node must replicate thatchanged atom on a “peer-to-peer” basis; i.e., to all archival nodes andonly those transactional nodes that contain that same atom.

A “garbage collection” process, described in greater detail later, canoccur on archival and transactional nodes. The process removes inactiveatoms from transactional and archival nodes. As a result, atransactional node can store those atoms that are then currentlyrelevant to user applications in random access memory at that node.Thus, the database request engine 41 “sees” the entire database as beinglocal and is not aware that it is operating in a multi-node environmentand without a complete copy of the database at its node. Archival nodeshave the option of purging the contents of an atom after it has beenserialized to disk thereby reducing the size of the memory required forstorage. If an archival node receives a replication message for such anatom, the archival node must fetch the content from disk storage beforeapplying the information from the atom being replicated.

With this general background, each atom type will now be described at a“logical” or functional level. This information, in conjunction withfurther discussions of the operation of this invention, will enable aperson of ordinary skill in the art to make and use this invention inany of a variety of implementations, including implementations basedupon object oriented programming.

FIGS. 4A and 4B depict the database engine 41 and typical set of atomsthat might reside in a transactional node 32 at any given time. In thisexample, the transactional node hosts a Master Catalog atom 70, aTransaction Manager atom 71, a Database atom 72, a Schema atom 73, aTable atom 74 and a Table Catalog atom 75. There is only one MasterCatalog atom 70, one Transaction Manager atom 71 and one Database atom72 per database. The Transaction Manager atom 71, the Database atom 72and the Schema atom 73 are created when a database request engine 41creates a new database.

Referring to FIG. 4A, a Master Catalog atom 70 tracks the status oftransactional and archival nodes in database system 30 of FIG. 1. Italso can be considered as an active index that creates and monitors theTransaction Manager atom 71, the Database atom 72, each Schema atom 73,each corresponding set of Table atoms 74 and Table Catalog atoms 75, andSequence ID Manager 82.

The Table Catalog atom 75 acts as an active index and creates andmonitors Index atoms 76, Record States atoms 77, Data atoms 78, BlobStates atoms 80 and Blob atoms 81 associated with a single table. Thatis, there is one Table Catalog atom 75 for each table.

FIG. 4B is useful in understanding the interaction and management ofdifferent atom types. In this context, neither the Master Catalog atom70 nor the Table Catalog atom 75 performs any management functions. Withrespect to the remaining atoms, the Database atom 70 manages each Schemaatom 73. Each Schema atom 73 manages each related Table atom 74 andSequence ID Manager atoms 82. Each Table atom 74 manages itscorresponding Table Catalog atom 75, Index atoms 76, Record States atoms77, Data atoms 78, Blob States atom 80 and Blob atoms 87.

Still referring to FIG. 4B, the database request engine 41 communicateswith the Master Catalog atom 70, Transaction Manager atom 71, theDatabase atom 72, each Schema atom 73, each Table atom 74 and theSequence ID Managers 82. The database request engine 41 acts as compilerfor a high-level language such as SQL. As a compiler, it parses,compiles and optimizes queries and obtains metadata and data from atomsfor the formation of the various fragments of data base information.

Each atom has certain common elements and other elements that arespecific to its type. Referring to FIG. 5, a Master Catalog atom 70includes common elements 70A through 70I. Element 70A is a uniqueidentification for the atom. As there is only one instance of a MasterCatalog atom that is replicated to all nodes, the Master Catalog atom ID70A is given a fixed number, typically “1.” As a general rule, pointers70B and 70C identify the Master Catalog atom and the creating catalogatom, respectively. For the Master Catalog atom, both pointers identifythe Master Catalog atom itself.

Each atom must have a chairman. The chairman performs functions asdescribed later. Element 70D is a pointer to that node where thechairman for that atom resides.

Each time a copy of an atom is changed at any transactional node, itreceives a new change number. Element 70E records that change number.

Whenever a node requests an atom from another node, there is an intervalduring which time the requesting node will not be known to othertransactional nodes. Element 70F is a list of all the nodes for whichthe supplying node must relay messages to the requesting node from allother nodes that contain that atom until the request is completed.

Operations of the database system are also divided into cycles. A cyclereference element 70G provides the cycle number of the last access tothe atom. Element 70H is a list of all active nodes that contain theatom. Element 70I includes several status indicators.

Still referring to FIG. 5, a global node IDS entry 70J contains an IDmanger for assigning a unique identifier for each active node in thesystem. As known, such identifiers are long character strings. A localnode IDS entry 70K includes a range of numbers up to the total number ofnodes that can attach to the system. Together these entries provide thecorrespondence between the two types of identification. Use of localnode IDS increases efficiency.

When a transactional node joins the database system 30 in FIG. 1, aconnection manager 70L effects that process. A specific implementationfor enabling the transactional node to join the database system isdescribed later. The joining node uses a pending node status entry 70Mto indicate that it will not have a global address for a responding nodeuntil it receives further communications from that responding node. Adatabase UUI entry 70N contains the universal unique identification forthe database.

The entries at 70P are important because they link all the atoms forwhich the Master Catalog atom 70 acts as an active index. As previouslystated, these include the Database atom 72 and each of Schema atoms 73,Table atoms 74 and Table Catalog atoms 75.

A password entry 70Q is representative of a means for authenticating aconnection into the database. Actual and software version entries 70Rand 70S allow the system to operate with backward compatibility when anewer version of the software is installed. The actual software entry70R identifies the software version then in use; the software versionentry 70S, the number corresponding to the most recent installedversion. This permits individual nodes to be updated to newer versionswithout requiring other nodes to be updated and without closing thedatabase for access by all nodes.

Still referring to FIG. 5, the Master Catalog atom 70 also includes apointer 70T to the Transaction Manager atom 71, a pointer 70U to aconfiguration object, a pointer 70V to a garbage collection thread and apointer 70W to a ping thread. The ping thread operates periodically andindependently of other operations at a node, It “pings” each other nodeto provide information that can be used in the determination ofcommunications efficiency of a corresponding path. For example, if nodeN1 in FIG. 1 has the option of communicating with either node N2 or N5,node N1 could use the ping information in the selection of the mostefficient of the communications paths to nodes N2 and N5 for thatcommunication. Other selection processes might also be substituted oradded.

Referring to FIG. 6, there is one Transaction Manager atom 71 for eachdatabase and it is created during the same process that creates theMaster Catalog atom 70. The Transaction Manager atom 71 creates, tracksand ends database transactions in response to database commands from thedatabase request engine 41. A Transaction Manager atom 71 includeselements 71A-71I that correspond to like elements in the Master Catalogatom. However, element 71A is the identification of the TransactionManager atom 71. Elements 71B and 71C both point to the Master Catalogatom 70.

An ID manager 71J provides unique transaction sequence identificationsand maintains an active transactions list 71K, a committed transactionslist 71L and a failed transactions list 71M. Element 71N stores commitsequence information. The ID manager 71J assigns a transaction ID at thestart of each transaction. Each transaction ID is unique, but notnecessarily sequential. A local Transaction Manager atom assigns acommit sequence number to element 71N when a transaction commits.Sequence numbers are sequential and each is specific to the node thatrequested the transaction. A transaction-transition event counter 71Pidentifies discrete events that occur during each transaction, such asthe start of the transaction and the successful committing of thetransaction. Such counters are useful when multiple transactionsinvolving the same information overlap.

Referring to FIG. 7, the Database atom 72 is created at the same timethe Master Catalog atom 70 and Transaction Manager atom 71 are created.The Database atom 72 identifies each of the Schema atoms 73. TheDatabase atom 72 may be involved with an authentication process when anew user attempts to join the database. It may also include other dataconcerning the authorization levels.

Basically, the Database atom 72 includes elements 72A-72I correspondingto like elements in FIG. 5. Element 72A is the Database atomidentification. Each of pointers 72B and 72C identify the Master Catalogatom 70. A schema name-schema ID registry 72J relates schema names toSchema atom identifications.

Referring to FIG. 8, a Schema atom 73 creates and tracks Table atoms forthat schema. A Database atom 72 may manage multiple Schema atoms andeach Schema atom may interact with multiple Table atoms. The Schema atom73 includes elements 73A-73I corresponding to elements 70A-70I in FIG.5. Element 73A is the unique Schema atom identification 73A and elements73B and 73C are pointers to the Master Catalog atom 70. A table has anunique name within a schema. A table name-table atom ID registry 73Jprovides the correspondences between each table name and thecorresponding table atom. Each schema sequence has a name. A sequencename-sequence ID manager registry 73K provides the relationship betweenthose names and corresponding sequence ID managers associated with eachSchema atom, such as sequence ID managers 82 in FIGS. 4A and 4B.

FIG. 9 provides a logical view of a Table atom 74 that incorporatesmetadata relating to fields, formats, indices and types and that manageseach of the Index atoms 76, Record States atoms 77 and Blob States atoms80 for that table. It also creates and tracks data within a table. Tableatom 74 includes elements 74A-74I that correspond to elements 70A-70I inFIG. 5. Element 74A includes the unique Table atom identification,elements 74B and 74C both point to the Master Catalog atom. Pointer 74Jidentifies the corresponding Table Catalog atom. Element 74K contains alist of all fields for the table.

Each Table atom has several ID managers. A pointer 74L points to an IDmanager that provides each field with a unique identification. Pointers74M, 74N, 74P and 74Q identify separate ID managers for assigningidentifications to Index atoms, Data atoms, Blob atoms and subtypes,respectively. Element 74R is a list of the existing subtypes. Arrays 74Sand 74T provide the locations of Record States atoms and Blob Statesatoms, respectively.

Now referring to FIG. 10, there is one Table Catalog atom for each Tableatom. Each Table Catalog atom 75 is created when a Table atom iscreated. In turn, a Table Catalog atom creates and tracks atoms specificto one table including the Index, Records States, Data, Blob States andBlob atoms. Each Table Catalog atom 75 includes elements 75A-75I thatcorrespond to elements 70A-70I in FIG. 5. Element 75A is a unique TableCatalog atom identification as assigned by the Master Catalog atom. Bothelements 75B and 75C point to the Master Catalog atom 70. An ID manager75J provides unique atom identifications for each of the Index, RecordStates, Data, Blob States and Blob atoms. A list 75K identifies allatoms associated with a corresponding Table atom. Pointers in element75L identify the location of each atom at the local node associated withthe corresponding Table atom. A series of lists 75M identify, for eachatom, a list of the nodes with replications of that atom. Bitmaps 75Nprovide a convenient means for identifying other objects and directorieswhen the atom is in an archival node.

Referring to FIG. 11, there is one Index atom 76 for each index in atable, and there may be multiple Index atoms per table. Each Index atomincludes elements 76A-76I that correspond to elements 70A-70I in FIG. 5,respectively. Element 76A is the unique Index atom identification asassigned by the corresponding Table Catalog atom. Pointers 76B and 76Cidentify the Master Catalog atom and the Table Catalog atom,respectively. Element 76J contains a binary tree of index nodes toprovide a conventional indexing function. Element 76K contains the indexlevel. Such index structures and operations are known to those skilledin the art.

Referring to FIG. 12, a Record States atom 77 manages record versionsand state for a fixed range of record numbers within a single table.Thus, a given Table atom may manage multiple Record States atoms. EachRecord States atom includes elements 77A-77I that correspond to elements70A-70I in FIG. 5. Element 77A includes the Record States atom ID thatthe creating Table Catalog atom assigns. Pointers 77B and 77C identifythe Master Catalog and the Table Catalog atoms, respectively. Element77J is an array for locating all the Data atoms managed by the RecordStates atom 77. Element 77K contains the record number for a “baserecord”. That is, each Data atom stores multiple records. Element 77 isa pointer to the corresponding Table atom.

In database applications to which this invention is directed multipleusers can produce multiple versions of the same record. A preferredembodiment of this invention uses multi-version concurrency control(MVCC) to ensure that a transaction never has to wait for the databaseby allowing several versions of a record or other object to exist in thedatabase simultaneously. Consequently, each Record States atom 77includes metadata about each record version. Entry 77M is a bitmap foridentifying the location of each versioned record that is useful ingarbage collection.

The Record States atom 77 includes, for each version 77N of a record, atransaction ID 77P to identify the transaction that generated theversion. A format version entry 77Q identifies the version number forthe table sub-type that existed when the record was inserted. Thisformat identifies the physical order of the record and identifies thesubtype to which the record belongs of the database program that was inuse at the time the record version was created. Element 77R includes arecord version sequence number; element 77S, the location of the nextolder, or previous, version of the record. An index 77T to the data atomarray 77J and the base record identification 77K together provide theaddress for the actual slot 77U in the Data atom with the recordversion.

FIG. 13 depicts a Data atom 78 with elements 78A-78I that correspond toelements 70A-70I in FIG. 5. In the Data atom 78 element 78A is the Dataatom identification 78A assigned by the Table Catalog atom. Elements 78Band 78C are pointers to the Master Catalog atom and to the correspondingTable Catalog atom, respectively. An ID manager 78J assigns a recordslot identification for each record in the Data atom 78. Element 78Kidentifies, for each record in the Data atom 78, the address and lengthof that record. Element 78C represents data records and versionsthereof.

Now referring to FIG. 14, databases also store “blob records.” A “blobrecord” typically is a collection of binary data stored as a singleentity in the database. Blob records do not exist in versions. A BlobState atom includes elements 80A-80I that correspond to elements 70A-70Iin FIG. 5. Element 80A has the Blob States atom unique atomidentification. Elements 80B and 80C are pointers to the Master Catalogand the Table Catalog atoms, respectively. List 80J identifies all theBlob atoms managed by a single Blob States atom 80. Entry 80K providesthe identification of the base Blob record. Element 80L points to thecorresponding Table atom. For each blob record, the Blob States atomincludes an index 80M to the Blobs atom. Element 80N identifies the slotin a Blob atom for the blob record.

FIG. 15 depicts a Blob atom 81 with elements 81A-81I that correspond toelements 70A-70I in FIG. 5, respectively. Element 81A is the atomidentification assigned by the Table Catalog atom. Elements 81B and 81Care pointers to the Master Catalog atom and to the corresponding TableCatalog atom, respectively. An ID manager 81J assigns a blob slotidentification to each blob in the Blob atom 81. Element 81K identifies,for each blob in the Blob atom 78, its address and length. Element 81Lrepresents all the blob records assigned to the Blob atom.

In summary, each atom has a relationship with only a fragment of thedatabase. For example, the Database atom 72 contains metadata thatidentifies the schema for the database. Each Schema atom 73 containsmetadata that identifies all the tables associated with that schema. Foreach table, a Table atom 74 and a corresponding Table Catalog atom 75provide metadata about the table including such information as theidentification of fields and their properties. Record States atomsinclude metadata about a group of records. Data atoms includeinformation about each data record with pointers to slots that containthese records and various versions. Blob States and Blob atoms containsimilar information about blob records.

Messages

As previously indicated, communications between any two nodes is by wayof serialized messages which are transmitted asynchronously using theTCP or another protocol with controls to maintain messaging sequences.FIG. 16 depicts the basic syntax of a typical message 90 that includes avariable-length header 91 and a variable-length body 92. The header 91includes a message identifier code 93 that specifies the message and itsfunction. As this invention envisions a scenario under which differentnodes may operate with different software versions, the header 91 alsoincludes an identification 94 of the software version that created themessage. The remaining elements in the header include a localidentification 95 of the sender (i.e., from the Master Catalog atom inFIG. 5) and information 96 for the destination of the message, namely acatalog atom (e.g., a Table Catalog ID 75A in FIG. 10) and an atomidentification 97 (e.g., a Record States ID 77A in FIG. 12). From thisinformation, the recipient node can de-serialize, decode and process themessage.

FIG. 17 depicts a set of messages having the syntax of FIG. 16 for aspecific embodiment of this invention. Each performs a specific functionas will now be described.

As briefly discussed previously, when a message is to be sent, there aredifferent communications paths to different nodes. For example, if onenode, as a requesting node, needs to obtain an atom, replications ofthat atom may be located in multiple other nodes. In this embodiment,“pinging” provides selection information useful for selecting the bestpath corresponding node. Pinging, as known, involves determining timefor a “ping” command to reach its destination and for an acknowledgementmessage to be received. In this embodiment of the invention, each nodeperiodically uses a helper class to send a Ping message 110 to each ofthe other nodes to which it connects. Each receiving node uses a helperclass to return a Ping Acknowledge message 111 that contains the pingtime. Each node accumulates this information about the time to send andreceive these messages in a node object described later with respect toFIG. 8. When one node prepares to send a message to one of multiplenodes, the transmitting node analyzes factors including, but not limitedto, the accumulated ping data to select one of the nodes as thereceiving node for that message.

A next set of messages are involved with the connection of a new nodeinto or previously inactive node back into the database system 30 inFIG. 1. When such a node, e.g., transactional node N2, wishes to connectto the database system 30, it initiates a connection process describedin detail later with respect to FIG. 19. Referring to FIG. 17, once thatprocess identifies an active node for receiving messages, the joiningnode sends a Connect message 112 to the selected node. The selected nodereturns a Welcome message 113 and a New Node message 114 to all otherconnected nodes in the database system 30. Each of the other connectednodes transmits its own Welcome message 113 to the joining node. Whenthis message sequence completes, the joining node can then take furthersteps to obtain various atoms.

Archival nodes can operate in either an active mode or a synchronizingmode when they are synchronizing to another node. A helper class in thearchival node transmits a Node State message 115 to alert all othernodes of any status change in that archival node.

A next set of messages are involved when a node, as a requesting node,retrieves a copy of an atom from another node. For example, after a nodejoins the database system 30 in FIG. 1, it generally requests a copy ofthe Master Catalog atom. The process is described in greater detail inconnection with the explanation of FIGS. 20 and 21.

Still referring to FIG. 17, the requesting node issues an Object Requestmessage 116 to a selected node which generally returns an Object message117 with the requested atom. The selected node also sends an ObjectAvailable message 118 to all other nodes with that atom. Each node thatreceives an Object Available message 118 from the selected node returnsan Object Acknowledged message 119 to the selected node. The selectednode sends an Object Complete message 120 node to the requesting nodeafter the selected node receives all the Object Acknowledged messages119.

In some situations the selected node sends an Object Unavailable message121 to announce that the selected node has dropped the requested atom. ABounce Object message from the selected node indicates that therequested atom is not found in the Master Catalog atom or one of theTable Catalog atoms. This may occur when an update transaction isunderway and the selected node does not respond to the Object Requestmessage 116 because the garbage collection process has collected thatatom before receiving the Object Request message. As a response, therequesting transactional node can select another node in the databasesystem with the atom.

The database request engine 41 in FIG. 1 and FIGS. 4A and 4B canperiodically generate a Register Object message 123 or an UnregisterObject message 124. These messages are directed to atoms that include aregistry, such as Database and Schema atoms. An Object Delete message125 is sent from a node when a user at that node issues a command todelete some item, such as a table.

Whenever a local node is updated or modified, its change number isincremented. Every replication message contains that atom's local changenumber. Every atom tracks the most recent change number for each node.When an archival node receives a copy of a modified atom, it copies thechange numbers for the atoms, clears the change numbers and thenserializes the atom to disk. If a change has been made, the changenumber will not be zero. The archival node sends an Object Writtenmessage 126 with the change number written to each node. Each receivingnode compares it own change number with that in the message. Then thenode can update the status for the atom to note that the atom has beenarchived and is a potential candidate for garbage collection.

As previously indicated, each atom must have a unique identity. When afirst atom of a particular atom type (e.g., a new Table atom) iscreated, the creating transactional node is designated a Chairman forthat Table atom. Rules for governing the “chairmanship” are discussedlater. Whenever a transactional node needs to create a new atom type, itsends an ID Request message 127 to the Chairman if it does not have anavailable identification. The Chairman generally returns an IDDelegation message 128 which includes a block of at least one uniqueidentification from its allocation of free identification values. Thisprocess is described in greater detail with respect to the process ofFIG. 20.

Referring to FIGS. 4A and 4B, a Table atom 74 can send any of a numberof messages. If the database request engine 41 initiates a process foradding a new field, the Table atom at that corresponding transactionalnode generates the new structure and sends a Table Field Added message129 that replicates the change to all other nodes that include thatTable atom. If a transactional node updates a field, a subtype or fieldcharacteristic that changes the table format, that node issues a TableFormat message 130. A Table Request Records message 131 is generatedwhenever a node needs to create a new Record States or Blob States atom.Only a chairman can create this atom; and the chairman broadcasts aTable Records Object message 132 when this occurs.

Each time a transactional node inserts a new record in a table, itproduces a Table Record message 133. Whenever it becomes necessary tocreate a new index, as when an indexed field is added to a table, thecreating Table atom replicates the new Table atom. At this time, theindex is set to be a write-only index. After all the related processesinvolved have been completed, the node sends a Table Index Added message134.

Any time a Table atom creates a Blob States atom for a blob, the Tableatom generates a Table Blobs Object message 135. A Table Blob message136 indicates that a new blob has been created.

In a database that utilizes types and sub-types, the database requestengine 41 in FIG. 1 will generate commands to cause a Table atom toassign a new table-type identification. When this occurs, a Table Typemessage 137 is replicated to all nodes with like Table atoms.

A Table Record Expunge message 138 provides the record number onspecific Record States atom. A Table Garbage Collect message 139 isgenerated by a Chairman for a Table atom when it is determined that arecord within that table contains an unusually long chain of backversions or other criteria. The result is that “unused” atoms are“emptied” of data.

A Record States atom 77 in FIGS. 4A and 4B also produces severalspecialized messages. If it becomes necessary to update a particularrecord, the database management system of this invention creates a newversion of that record. Referring back to FIG. 17, the correspondingRecord States atom generates a Record Update Request message 140 that isdirected to the Chairman for that atom to seek permission to update thatparticular record. The Chairman responds by generating a Records UpdateResponse message 141 that grants or denies permission to update thatrecord. If the Chairman grants permission, the requesting Record Statesatom performs the update and sends a Records Update message 142 with thenew version of the atom to each node with a copy of that atom.

A Data atom stores up to some maximum number of records and versionsthereof. A corresponding Record States atom monitors the size of theData atoms it manages. If a Record States atom determines that a managedData atom has exceeded that size, it generates a new Data atom andreplicates that new Data atom by means of a Records Data Object message143.

A Record States atom generates a Records Record message 144 forreplicating any new record version. Periodically, a Table atom Chairmaninitiates a process by which a Record States atom identifies recordversions that are older than the oldest active transaction. When thisoccurs, the Chairman's Record State atom transmits a Records Prunemessage 145 that enables those older record versions to be deletedduring a subsequent garbage collection process. If a situation ariseswherein it becomes necessary to rollback a transaction, a Record Statesatom generates a Backout Record message 146 that updates the backoutrecord.

There is also a set of index-specific messages. As known an index has anoptimum maximum size; and if the index exceeds that size, the indexshould be split. In accordance with this invention, only a Chairman cansplit an Index atom. The Chairman can do this unilaterally or inresponse to an Index Split Request message 147 from another copy of thatatom. When the Chairman causes the split, the Chairman generates anIndex Split message 148 that contains a split index. After the split,the Chairman sends an Index Prune message 149 to truncate the originalIndex atom following the split. Each time an index node is added to theindex, it generates an Index Node Added message that contains an indexkey, record identification and other information for the new index. Whenan index has been fully populated and therefore is ready for use duringretrieval operations, a Table Index Ready message 151 is generated. Aspreviously indicated, adding a table index generates an Index atom thatis a write only index and that is not readable. The Table Index Readymessage 151 makes such a write-only index readable.

A Blob States atom identifies a slot in a Blob atom by generating aBlobs Blob message 152.

A Data Record Message 153 contains the slot number and the recordlength. It also includes the data record.

As the state of a transaction changes, the Transaction Manager atom 71for a given transactional node generates Transaction State messages 154.These indicate whether the current status of the transaction is in anactive state, a pre-commit state, a commit state or a rollback state.Under certain circumstances it is possible that a request related to onetransaction will be blocked by another transaction on another node. Inthat event, the Transaction Manager atom receives a Transaction Blockagemessage 155. If a transaction is deadlocked and must be rolled back, theTransaction Manager atom associated with the node causing the deadlockgenerates a Transaction Deadlock message 156 causing the transaction tobe rolled back.

The Master Catalog or any Table Catalog atom on an archival node canrequest the time an atom was last written. This occurs when a requestingnode sends a Request Write Times message 158. The recipient of thatmessage then returns those requested times in a Write Times message 159.

The foregoing messages constitute a set by which the various proceduresneeded to maintain a database management system incorporating thisinvention can be handled properly. As will be apparent, each message hasa minimum of overhead in a header. Each message can be reasonably short.When used with TCP or other messaging protocol, the messages must besent sequentially and, at any given node, on receipt they must behandled in the same sequence in which they were sent even by differentnodes.

Methods

It will now be helpful to a further understanding of this invention todescribe some basic methods that relate to various aspects of theoperation of this invention. Variations from each will be apparent tothose of ordinary skill in the art.

FIG. 18 is a flow diagram of the operations that occur in differentnodes in the database system 30 of FIG. 1 when a node joins the network.For purposes of this description, assume that Node 5 in FIG. 1 is tojoin the database system; it is designated to be joining transactionalnode 170. As a first process, the joining transactional node 170 usesstep 171 to establish a TCP connection with a selected node. Basically,the joining transactional node 170 sends a message to a fixed locationthat identifies a database. A connection broker, not shown but as knownin the act, responds to this request by denying or granting access tothe database system. If the connection broker grants access, it selectsa node, such as transactional node N1, as a selected node 172. Then theconnection broker sends a message to the joining transactional node 170with a designation, as by a port number, of the selected node 172. FIG.18 also represents as a group 173 all other active transactional andarchival nodes in the database system.

Once the connection is established in step 171, the joiningtransactional node 170 uses step 174 to send a Connect message to theselected node 172. The selected node 172 responds to the Connect Messageat step 175 by updating its Master Catalog atom with its connectionmanager, assigning a local node ID to the joining transactional node 170and adding that node to an array of local nodes in its node object, anexample is shown in FIG. 19.

FIG. 19 depicts a node object such as described in connection with step175 of FIG. 18. It contains a pointer 400A to the socket for the nodeand a pointer 400B to the Master Catalog atom at the node and a pointer400C to the connection manager in the Master Catalog atom. Pointer 400Didentifies the thread used to listen for incoming messages and pointer400E identifies a socket buffer for receiving messages. The messagelistener waits for a message, determines the message type and thenprocesses the message to completion.

The node object 400, like all the atoms, includes a global node ID 400Fand a local node ID 400G of the node to which this node is listening.Element 400H is a pointer to a queue of messages that are waiting to besent from the node. Elements 400I and 400J contain the identificationsfor the local port and the remote ports. Element 400K contains theversion number for the software operating at the remote node. A nodetype element 400L indicates whether the remote node is a transactionalnode, an archive node undergoing a synchronization process or an on-linearchival node.

Element 400M contains the name for the local node; element 400N, thename for the remote node. Element 400P is a pointer to the currentmessage being processed. Elements 400Q and 400R identify the time of thelast ping operation and the ping time. As previously indicated, eachnode generates a sequential commit sequence number in response to eachcommit operation for a transaction initiated at that node. Element 400Scontains this number. Element 400T indicates whether this node object isthe node object for this node.

Referring back to FIG. 18, at step 176 the selected node 172 sends aWelcome message to the joining transactional node 170 that contains theglobal node ID. Then, the selected node broadcasts a New Node message instep 177 to the group 173 of all other transactional and archival nodes.

Each node in the group 173 responds to the New Node message by recordingthe global ID and assigning a local ID of the joining transactional nodeand updating a local list of all connected nodes in their respectiveMaster Catalog atoms at step 180. Each then uses step 181 to send aWelcome message to the joining transactional node 170. Upon completionof this process, the joining transactional node 170 has a full list ofall the active nodes including the selected node 172 and all the nodesin the group 173.

When the joining transactional node 170 receives the Welcome messagefrom the selected node at step 182, it sends an Object Request message(step 183) to the selected node 172 requesting a copy of the MasterCatalog atom. After the selected node 172 has updated the various itemsof information in its Master Catalog atom, the selected node implementsstep 184 to serialize its Master Catalog atom in an Object message thatis sent to the joining transactional node 170 and broadcasts an ObjectAvailable message to all the other nodes in the system. Thus, the MasterCatalog atoms in each node are updated and synchronized.

Without waiting for the receipt of the Object message, the joiningtransactional node can also begin the process of step 185 for retrievinga copy of the Database atom and the Transaction Manager atom from theselected node 172.

Each other node that receives the Object Available message responds instep 186 by sending an Object Acknowledged message back to the selectednode.

The database request engine in the joining node initiates this sequence.Thus, when the method of FIG. 18 has been completed, the joiningtransactional node 170 is connected to the database system and, as shownin FIGS. 4A and 4B, includes a copy of the Master Catalog atom 70,Transaction Manager atom 71 and the Database atom 72. The joiningtransactional node 170 thereafter will either create or obtain copies ofother atoms on an as-needed basis.

During some operations, a transactional node might create of a newtable, necessitating the creation of a new Table atom. FIG. 20 disclosesthat process 190 where node A is a requesting node, atom X is the atomthat requests and will manage a new atom Y. For creating a new Tableatom Y, atom X would be a Schema atom and the local catalog Z would bethe Master Catalog atom. Step 191 represents preparatory functions forthe request to obtain an instance of atom Y. Each time an atom ischanged, it is assigned a change number; the initial value typically is“0”.

At step 192, the local catalog Z creates that instance of atom Y with nocontent and designates the local node as the chairman for atom Y. Then aprocess 193 allows the local catalog Z to assign an object ID to newatom Y. The specifics of such a process are shown and described withrespect to FIG. 21.

Next, the local catalog Z sets an exclusive lock to allow changes to itto occur without any influences from outside automation. While the lockis in place, the local catalog Z sets the status of new atom Y to a“dirty” status and to a “non-open” status. The “dirty” status indicatesthat the new atom Y has not been replicated to an archive. The“non-open” status indicates that the new atom Y is not yet available toother nodes. At step 195 the local catalog Z updates itself and thenreleases the exclusive lock. At step 196 catalog Z broadcasts an ObjectAvailable message identifying atom Y to all other instances of catalog Zin the transactional and archival nodes.

At step 197 atom X, as the managing atom for new atom Y, populates theinstance of atom Y and sets the status for atom Y to “open” indicatingthat the new atom can be replicated. Some time thereafter an archivalnode will save a copy of the new atom to persistent storage. That is,the archival node will respond to the receipt of the Object Availablemessage by requesting a copy of atom Y thereby to provide theredundancy. When this is complete, the receipt of a Object Acknowledgedmessage from the archival node will cause the “dirty” status to bechanged and this change will then be reflected to all other nodes thathave a copy of atom Y.

The assignment process 193 in FIG. 20 and like assignment processes areused in various stages of the operation of this invention for assigningobject IDs. FIG. 21 depicts this assignment process in greater detail.Specifically, when a catalog atom wants to assign an object ID itdetermines at step 200 if it has a local ID available to it. If it does,control passes to step 201 that assigns the available ID in response tothe request. If a local ID is not available, control passes to step 202to determine whether the catalog atom at this node has a “chairman”status. If it is, the chairman has the authority to identify availableIDs directly and control passes to step 201.

As will be recalled, when at least one other node exists for theparticular atom, each atom contains a list of nodes that include copiesof the atom being requested. If this were a first request for the atomafter that atom had been created in accordance with the process of FIG.20, the corresponding catalog in the first node on the list is thechairman. Step 203 represents the process of selecting a node andidentifying the chairman. For the selection process, it is preferred toestablish communications with a transactional node first. Step 204represents the transmission of an ID Request message to the chairman.

When the chairman receives the ID request message at step 205, itobtains a block of available ID numbers (step 206). The chairmanidentifies the transactional node making the request as the site of thisblock of available ID numbers (step 207). Then the chairman sends an IDdelegation message at step 210 to the requesting node. When therequesting node receives the ID Delegation message from the chairman atstep 211, it stores the block of ID numbers at step 212 and then selectsthe first available ID for assignment in step 201. Referring back toFIG. 20, in that situation the process 193 transfers from step 200 tostep 202 directly to step 201 because the chairman is designated in step192 at FIG. 20.

Whenever the Database engine 41 in FIGS. 4A and 4B makes a request foran atom, a response 220 in FIG. 22 is processed. For example, assumethat the database request engine 41 in a requesting node 221 asks for acopy of atom Y (e.g., a Table atom) from a selected node 222 in adatabase with other nodes 223. When the database request engine 41 makesthat demand, step 224 determines whether atom Y is present in therequesting node 221. If it is, step 225 terminates the process becausethe requested atom is present. If it is not, control transfers to step226 whereby a local catalog Z creates an empty instance of atom Y anddeclares atom Y to be “unpopulated.” If the Database engine 41 wererequesting a Table atom 74, the Master Catalog atom 70 would performthis step. Step 230 then uses the previously described selection processto identify a selected node 222. The preference is to select any of thetransactional nodes before selecting the most responsive archival nodeas the selected node 222.

In step 231, the requesting node 221 sends an Object Request message foratom Y to the selected node 222. In response, the selected node 222 usesstep 232 to send an Object Message with the requested atom Y in itsserialized form with the node and sequence numbers.

At the same time, the selected node 222 broadcasts an Object Availablemessage to all other nodes 223. It also creates a relay list for allother nodes with a copy of atom Y. At this point in the process, theother nodes do not communicate directly with atom Y in the requestingnode because they are not aware that they should be sending replicationmessages for that atom to requesting node. Therefore, when any of theother nodes replicates its atom Y, the selected node 222 will relay themessage to the requesting node 221.

When the Requesting node 221 receives the Object message from theselected node 222, it conducts an accessibility analysis of the messageat step 233. If the message contains a current atom, atom Y processesthe message at step 236 and sends an Object Acknowledged message to theselected node at step 237.

All other nodes 223 use step 240 to respond to the Object Availablemessages by sending an Object Acknowledged message to the selected node222. The selected node 222 uses step 241 to monitor the ObjectAcknowledged messages. Specifically, it removes each of the other nodesfrom its relay list in response to each Object Acknowledged message andceases relays to that node. When all the other nodes 223 have beenremoved from the list, the selected node stops all relaying andbroadcasts an Object Complete message.

It is possible for another node to send a replication message thatreaches the requesting node 221 during the time between steps 226 and236 in FIG. 22. This can interrupt message processing. Consequently,when a replication message for atom Y in the above example is receivedat the requesting node while atom Y is unpopulated, it is placed in apending message list that is part of each atom, although not shown inany of FIGS. 5 through 13.

As previously indicated, this invention is particularly adapted to adatabase that interfaces with transactional processing techniques. Assuch, an appropriate approach for “committing” messages should beinvolved. FIG. 23 depicts one approach that assures the consistency ofdata in such an environment. Specifically, FIG. 23 depicts four nodes,namely: transactional node A 250, transactional node B 251,transactional node C 252 and archival node 253. It is assumed thattransactional node B 251 sends a Precommit message with a transaction IDsupplied by the Transaction Manager atom at that node at step 254. Themessage is routed to the archival node at step 255. When all theconditions for committing that transaction have been completed, thearchival node 255 issues a commit transaction message at step 256 and,at step 257, broadcasts that commit message. Each of the transactionalnodes updates its corresponding transaction number in response at step258.

As previously described with respect to the process for requesting acopy of an atom in FIG. 21, the requesting node performs theaccessibility analysis upon any received message at step 233. This testprovides assurance that any transactional node always operates withvalid information and involves an analysis of transaction ID numbers andcommit sequence numbers. An understanding of this analysis and otherfeatures of this invention will be facilitated by a furtherunderstanding of transaction IDs and commit sequence numbers, by ananalysis of the relative order of transactions and by an understandingof “atom skew.”

With respect to transaction IDs and commit sequence numbers and aspreviously stated, each transaction identifier is unique across theentire database system of FIG. 1. The purpose of a transaction ID is tobe a unique, permanent, system-wide mark indicating which transactioncreated a specific record version. Each transaction ID is assigned by alocal copy of a Transaction Manager atom 71 and one such TransactionManager atom will be the chairman that assigns blocks of identifiernumbers to the Transaction Manager atoms on each transactional node inthe database system. A Transaction Manager atom at a given transactionalnode assigns an unused number in an assigned block in order to eachtransaction that node starts. As a result, the transaction IDs of newertransactions started at a given node can be higher than the transactionIDs assigned to older transactions started on that same node. However,on a system-wide basis the transaction IDs do not imply anything aboutthe relative start times of different transactions.

Consequently, some method must be provided to assure that a transactioncan read a record version only if the transaction that created therecord version had committed before the reading transaction started. Inthis invention such a method for determining which record version toread is the transaction commit time for the transaction that created therecord version, not the start time. A transaction ID does not containits commit time, so the Transaction Manager atom on each node assigns acommit sequence number to each transaction based upon the actual commitoperation. Each transactional node generates its commit sequence numbersin an increasing sequence. If a transaction from a given node has acommit sequence number of 467, all transactions from that node withlower commit sequence numbers are certain to have been committed. Allnodes generate the same commit sequence numbers, so interpreting thenumbers requires both the number and the identification of thecorresponding node.

When a transaction commits, its Transaction Manager atom sends a Commitmessage to all nodes that include the corresponding transaction ID andcommit sequence number. When an atom serializes itself, it includes thehighest commit sequence number that it has seen from each node thatholds a copy of that atom. For example, assume nodes A, B and C containcopies of an atom Z and that node A generates a Object message for atomZ. The serialized form of that message will include the highest commitsequence number that node A has seen from itself and the highest commitsequence numbers it has seen from nodes B and C. The serialized messagefrom node A describes the state of transactions on all nodes that sharea copy of atom Y as node A sees it. It is possible that node B or node Cmay have actually issued higher commit sequence numbers for transactionsthat node A has not yet received or processed.

The Transaction Manager on each node maintains a transaction object foreach node in the database system. Each transaction object reflects thestate of transactions on all nodes and assigns each object two morenumbers that are local and continuously increasing. When the TransactionManager atom starts a transaction or receives a transaction transitionmessage that indicates that another node has started a transaction, theTransaction Manager atom creates a local transaction object with the newtransaction ID and assigns it a start number. When a local transactioncommits or when Transaction Manager atom receives a transactiontransition message that indicates that a transaction on another node hasbeen committed, a transaction end number is assigned to the transactionobject along with the commit sequence number. The start and end numberscome from the same sequence. As an example, if Transaction 123 has astart number that is higher than the end number of Transaction 453,Transaction 123 can read record versions created by Transaction 453 fromany node that executed Transaction 453.

Transaction start and end numbers are local; that is, they reflect thestate of transactions as seen on the local node. Different nodes assigndifferent values and see different ordering of transactions on othernodes. As will be apparent, delays can exist in receiving and inprocessing Transaction State messages. Each transaction runs only on itslocal transactional node. This database system prevents one transactionnode from “seeing” a transaction as committed before the transactioncommits on its local transactional node. For example, if node A startsTransaction 123 after receiving and processing the commit message fromtransactional node B for Transaction 453, Transaction 123 can read thechanges from Transaction 453, even if a transactional node C thatreceived the transaction commit and start messages in another order andconsiders the two transactions to be contemporary.

As neither of the transactions runs on transactional node C, theinformation is not relevant to transactional node C. However, thedifference between the view of the database system by each individualtransactional node can cause problems in certain circumstances.

With respect to “atom skew”, in accordance with one aspect of thisinvention, each node must process messages from another node in theorder that the other node sent the messages. However, all nodes operateindependently. Thus, at any given time, some nodes will have receivedand processed messages that other nodes have not yet processed. Somecopies of atoms will include changes that other copies do not. Thosedifferences do not matter to any node that has a copy because each copyof the atom is in a consistent state for that node. As previouslydescribed, whenever a transactional node changes an atom, the nodereplicates the changed atom to all other nodes that contain a copy ofthat atom. If transactional nodes B and C each contain a a copy of thatatom and transactional node B changes that atom, transactional node Bsends replications messages to transactional node C. While transactionalnode B is processing a transaction, it sends a Transaction State messageto transactional node C and replicates any atoms that transactional nodeB changes. When transactional node B commits the transaction by theprocess shown in FIG. 23, transactional node C should have received theTransaction State message indicating that the transaction has beencommitted. Transactional node C will process all the messages related tothe transaction before it receives the Commit message due to the factthat all messages will be processed in the order in which they weresent. Copies of atoms on different transactional nodes can differ, butall changes made by a transaction on any transactional node will be onevery other node before the other node sees the transaction ascommitted.

When viewing transactions from the system level, different transactionalnodes are not acting in synchronism. The times for a single messagebeing processed by different nodes can vary due to differences in theefficiency of the communications path and the number of messages thateach transactional node needs to process. The differences in processingtimes at different nodes must be taken into account. Consider threetransactional nodes: node A, node B and node C. Assume that node Bexecutes a transaction 768 that changes atom X and that node C has acopy of atom X. Assume that atom X at node B sends change messages tonode C and that there is some time lapse before node C processes thosechanges. Assume also that node B has assigned a commit sequence numberof 47 to Transaction 768. The Transaction Manager atom on node B sends aTransaction State message to all nodes in the database system. Alsoassume that node A requests a copy of atom X from node C after receivingthe commit message from node B, but before Node C completes processingthe transaction. Node A receives and processes the Transaction Statemessage from node B. From the perspective of node A, transaction 768 iscommitted and the highest commit sequence number for node B is 47.However, with this timing, the atom returned from node C does notreflect the changes made by the transaction at node B.

In accordance with this invention, when atom X on node C serializesitself for transmission to node A, it includes the highest commitsequence number from each node that has a copy of atom X. In this case,assume that the message would include a commit sequence number 97 fornode C and 46 for node B.

Referring to FIG. 22, node A as a requesting node creates an emptyinstance of atom X before asking node C for its contents. Theaccessibility analysis in FIG. 22, obtains the current highest commitsequence number for each node as seen by node A. It also expands theserialized message with Atom X to obtain the current highest commitsequence numbers for each node as seen by node B. In this comparison,the accessibility analysis will determine that the serialized commitsequence number in the message is 46, while its local highest commitsequence number for B is 47. Thus, Node A cannot use the serializedversion of atom X in its current state and must wait for atom X on nodeC to send it an Object Complete message. If the commit sequence numberis the same or higher, node A can continue to process the atom.

As previously stated, when node C sent the serialized copy of atom X tonode A, it sent an Object Available message to other copies of atom X,in this case, to the copy on node B. Atom X on node B sends an ObjectAcknowledged message to atom X on node C and adds the copy on node A toits list of copies of itself. Thereafter, atom X on node B will sendchange messages to its copies on both nodes A and C. Meanwhile, atom Xon node C processes the messages from node B, relaying them to node A.Atom X on node A processes the messages, bringing itself more and moreup to date. When atom X on node C processes the Object Acknowledgedmessage from atom X on node B and all other copies of atom X on othernodes, it sends an Object Complete message to atom X on node A.

In accordance with this invention each transactional node should operatewithout having to transfer any atoms to disk or other persistentstorage. This requires removal of inactive atoms from each transactionalnode in an expeditious manner. To achieve this goal, a helper class ineach node provides a garbage collection function called by a cyclemanager periodically to initiate a new garbage collection cycleindependently of other operations. More specifically, the cycle managerperforms an aging cycle whereby any atom referenced in a previous cycleis moved to the front on a least recently used (LRU) list in the MasterCatalog atom for the node. The cycle manager obtains an exclusive lockto assure that no other threads are active with respect to a previouscycle.

The cycle manager then starts the record garbage collection thread for atable atom that is marked for record garbage collection. If the currentamount of memory at the node exceeds a specified amount defined by aconfiguration object identified by the pointer 70U at FIG. 5, thegarbage collection thread process loops through the Master Catalog LRUfrom the least recently used to the most recently used atoms. Itclassifies an atom as a candidate for a garbage collection candidate ifthat atom: (1) is not active, (2) has not been referenced in the currentaging cycle, (3) is not “object incomplete” atom, (4) has been changedlocally and not yet written to an archival node and (5) is a catalogthat has no memory resident atoms. An atom in an archival nodeadditionally must not have been serialized to disk.

If the garbage collection process determines that all the foregoingconditions have been met, there are two options. If the node is anarchival node and there are other instances of the atom at other nodes,the content of the atom is “purged”. Otherwise the atom is requested todrop itself which it does by first checking with its creating catalogatom for a final test. If that test is passed, the catalog atom clearsits pointer to the candidate atom which broadcasts an Object Unavailablemessage to other nodes that contain instances of the candidate atom andthen deletes itself. This loop continues on an atom by atom basis untilthe working memory is within acceptable limits.

Two mechanisms are involved with this process. When a Catalog atom isasked to find an atom for classification, the Catalog atom sets itscycle reference entry to the current cycle number. In addition,Transaction Manager, Database, Schema, Sequence and Table atoms obtain ashared lock on a current cycle so that methods in those atoms can holdatom pointers without having to increment an atom use count to preventan object or an atom from being garbage collected.

FIGS. 19 and 20 discuss “chairmanship.” As indicated in FIG. 20 when anatom is created, the creating node is designated as the atom chairmanand establishes an ordered list of nodes for the atom. When a nodecreates an atom, it is the only entry in the ordered list. The firstnode in the list is the chairman.

When another node later requests a copy of that atom, the selected nodeplaces the identification of the requesting node in the ordered listjust after itself, whether it is the chairman or not. As a result, ifthe node designated as a chairman for any atom becomes inactive for anyreason, every other copy of that atom has the ordered list of nodes.Going through the ordered list, the next chairman is the first remainingtransactional node on the list. If there are no transactional nodes onthe list, the first non-synchronizing archival node is designated.

It may now be helpful as an aid in understanding the interaction amongdifferent nodes and atoms within a node to discuss a simple databasequery. Assume the database request engine at a transactional nodereceives a database query to select all records in a table “member” witha postal code of “01944.” It is assumed that the Transaction Manageratom and Table atom are located at the local node, that all queryprocessing has been completed and that an Index atom exists for a “zip”field in the “member” table.

Initially the database request engine 41 in FIG. 2 issues a command tothe Transaction Manager atom to begin a new transaction whereupon theTransaction Manager atom assigns a transaction ID. Next, the databaserequest engine utilizes the Table atom for the “member” table todetermine if an Index atom exists for the “zip” field. If these twoatoms are at the local node, they are processed. If they are not, copiesof these atoms are obtained from other nodes before processingcontinues.

The Table atom for the “member” table utilizes information from thecorresponding Table Catalog atom to scan the index. This produces abitmap that identifies each “record” in the “member” table with thespecified zip code. As will be apparent, this bitmap may be limited to aparticular field or maybe the result of the logical combination ofindexes from multiple fields.

Next, a loop is established based upon the resulting bitmap. For eachiteration of the loop, the database request engine issues a call to theTable atom to process a fetch record method specified with thetransaction ID in the record. The Table atom selects an appropriateRecord States atom that is related to a Record atom by dividing therecord number by a fixed number that corresponds to the maximum numberof record IDs a Record States atom manages. Next, the Table atom uses afetch method in the selected Record States atom using the transaction IDand identified record number. For multi-version records, the RecordStates atom loops through any record versions to find the correctversion and the appropriate pointer to the corresponding Data atom. TheRecord States atom calls that Data atom with the data atom number thatpoints to the record and permits its retrieval. When this process iscompleted, the database request engine provides the user with arecordset that lists all the records with the specified postal code.

In summary, it will be apparent to those of ordinary skill in the artthat a database management system constructed in accordance with thisinvention provides an elastic, scalable demand-distributed dataprocessing system. The system is fault tolerant and has a high degree ofavailability. It is platform independent and operates to provide anatomic, consistent, isolated and durable database. Moreover, it canoperate over the internet without the need for high speed communicationspaths and is adapted for transactional processing that can beimplemented over a wide geographic area.

In summary this invention achieves all these objectives by implementingone or more of the following features. This invention fragments thedatabase into distributed objects that replicate on a peer-to-peerbasis. Each transactional and archival node determines which atoms areto be memory resident on a local basis. Catalog atoms track locations tolocal and remote copies of various atoms and identify the catalogs ofwhich they are members. Moreover each node can determine the best ofmultiple nodes from which to request a copy of the atom enablinggeographically dispersed systems.

This invention has been disclosed in terms of certain embodiments. Itwill be apparent that many modifications can be made to the disclosedapparatus without departing from the invention. Therefore, it is theintent of the appended claims to cover all such variations andmodifications as come within the true spirit and scope of thisinvention.

1. A database management system for a logical database comprised of datarecords organized into tables to be accessed from multiple transactionalnodes that process transactions related to the logical data base, saidsystem comprising: A) means for defining a set of atoms for storing inan atom a portion of metadata or data whereby a set of atoms containsall data and metadata, B) an archival node that stores all instances ofthe atoms in a de-serialized form in permanent storage thereby toconstitute a single store for the entire data base, C) means fortransferring atoms among the transactional and archival nodes asserialized messages wherein each transactional node comprises: i) meansfor responding to queries from users by establishing a sequence oflow-level commands for identifying atoms that are relevant to the query,ii) means for responding to the low-level commands by obtaining onlythose copies of existing atoms that are relevant to the query beingprocessed thereat whereby a copy of a given atom might exist at someother node or only at an archival node, and iii) means for replicatingany copy of a changed atom to the archival node and each transactionalnode in which a copy of that atom resides whereby changes are made toatoms in other nodes on a peer-to-peer basis and whereby anytransactional node only contains those atoms that pertain to the queriesbeing made users accessing the data base through that transactionalnode.